## Problem

The existing binary unpack path copies data into std::vector<B>:

    value.assign(src, src + bin_size);  // always allocates + copies

For callers that only need to read the binary payload (e.g. pass it to a
parser like GEOS WKBReader), this allocation is pure waste — the data is
already contiguous in the Unpacker's internal buffer.

## Solution

Add a second unpack_type overload that resolves when the caller declares
their argument as std::span<B const>:

    template<std::size_t E>
    void unpack_type(std::span<B const, E> &value) {
        // ... read header to get bin_size ...
        value = data_.subspan(position_, bin_size);  // zero-copy view
        increment(bin_size);
    }

data_.subspan() returns a non-owning view into the Unpacker's own buffer,
so no allocation or memcpy occurs. The span remains valid for the lifetime
of the Unpacker (i.e. for the duration of the unpack call chain), which
is sufficient for immediate-use patterns like deserialise → parse → discard.

## Safety

- Bounds are checked identically to the vector overload (position_ + bin_size
  > data_.size() throws std::out_of_range).
- The returned span is const-qualified (B const), preventing accidental writes
  back into the source buffer.
- Callers that need to own the data should continue using std::vector<B>.

## Backwards compatibility

Fully additive — existing code using std::vector<B> is unaffected. The new
overload is only selected when the target variable is declared as std::span.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>